Complex database systems often need to access objects stored on remote databases. For example, a bank may need to transmit a financial transaction across several databases in order to maintain integrity in their records. As another example, a shipping company may need to send package tracking information across several systems in order to make this data available to its customers.
A “cluster” is a system in which multiple database servers (“instances”) have access to the same database. A database to which the multiple instances have access is referred to herein as a “cluster database.” The persistent storage that stores a cluster database is accessible by all instances in the cluster. Typical database objects such as persistent tables, packages and procedures will be accessible from any instance of the cluster database.
In a cluster database, one or more instances of a certain class of objects may be stored on one or more database instances in a private area accessible only to that instance, e.g. in its volatile memory. For example, in a database cluster containing instances I1, I2, and I3, a particular object, O1, may be stored on I1 and I3 in their respective volatile memory, but may not be stored on I2.
Connecting to such objects in a cluster environment presents a unique challenge because the information destined for the particular object in a cluster database does not merely have to be delivered to the right database, but has to be delivered to the right instance (an instance containing the target object). To ensure that information is delivered to the correct database instance, database links could be allocated on an instance-by-instance basis.
Remote access of such objects on different databases happens through database links (“dblinks”). When a dblink is initialized, the user specifies various dblink configuration values, including a specific destination instance for the dblink. For example, a typical dblink configuration may appear as follows:    host=host1.oracle.com    port=300    protocol=TCP    username=fred    password=xyz    service_name=dbs1.oracle.com    instance-name=instance1This is known as an “instance dependent” dblink, because the destination instance is specified in the dblink.
After the dblink has been set up, the dblink may then be used to establish connections with the specified database instance. Connections are used for information exchange between a source database, and a destination database instance specified by the dblink. After a connection has been established, the processes communicate directly with each other to exchange information to/from the destination object.
Problems can arise when information is accessed from remote objects in a clustered database. For example, an instance in a cluster database system may fail. Upon failure of an instance, which contains a particular object, the object automatically migrates to another live instance. After the migration of a destination object, the propagation of information from sources outside the new provider instance to the migrated object will fail because the connections that had already been established at the time of the migration are to the previous provider instance. Furthermore, attempt to establish new connections will also fail, because the new connection attempts will use a dblink that points to the previous provider-instance.
Correcting the object access problems when a failover occurs requires the database administrator to drop the dblink associated with the failed node and determine the new provider instance of the target object. Once the new provider instance has been determined, the database administer creates a database link to connect to the new provider instance of the destination object. The inherent delay in the re-configuration leads to disruption and unavailability of the migrated objects for a certain time period.
When there are multiple such objects that need to be accessed remotely, the user needs to configure multiple separate instance-specific dblinks, one per object accessed. This will entitle duplication of all the connection and authentication information in several dblinks. Also, in the event that these remote objects are highly transient in nature with a high rate of arrival and departure of these objects, then these dblinks need to be dynamically created and dropped for each of these objects. This has adverse security and manageability consequences.
Based on the foregoing, it is clearly desirable to provide an improved method for connecting to objects residing in cluster databases, which allows access to migrated objects without intervention from a database administrator and greatly improves the security and management of such links